With the rapid development of an IPTV (Internet Protocol Television) service around the world, the video flow in the network is increasing constantly at a high speed, and the multicast has become one of the most important techniques in the data communication network. The demand of increasingly expanding market has a higher requirement for transmission quality of video service of network provider, and in order to improve the service experience of the IPTV user, a higher transmission quality, a quicker channel switching capability and a better network failure avoidance capability are required.
The multicast flow needs to run through a service provider side gateway, a core network, a service node and an access network from IPTV service provider to final user. Processing modes of the core network and the access network are different from each other in the aspect of the network failure avoidance, because both the two network types and the used multicast protocols are different. The core network is a network based on route forwarding, of which the used protocol is a PIM (Protocol Independent Multicast) protocol, while the access network performs forwarding based on a MAC (Media Access Control) address, and the multicast on demand uses an IGMP (Internet Group Management Protocol) protocol, and different network architectures and protocol types lead to the difference in quick switching mode when the network is faulted.
Referring to FIG. 1 please, the IGMPv2 (IGMP version 2) protocol is extensively used at present in the access network, which is a multicast group member management protocol. In general, one multicast group corresponds to one set of video programs, relating to three types of network elements: the first one is a multicast querier, which is responsible for querying and maintaining a state of each multicast group member, receiving and processing a request of the group member for joining and leaving the multicast group, and sending out a multicast flow from an access demanded by a user; the second one is a multicast group member (also called host), the host will send a request for joining and leaving the multicast group and receive the multicast flow sent from the querier when the user clicks and closes the multicast program; the third one is a non-querier, other routers with querier function in the same network, and when one querier in network is faulted, one non-querier will be switched to be the querier (if the number of non-queriers is more than one, the electing mode is the same with that of electing the querier). When there are many routers with querier function in one access network, certain rules (for example, according to a relation between sizes of IP addresses) will be used between the routers to choose one querier. A non-querier receives a query message sent from the querier regularly, and the non-querier starts a timer to wait for the coming of next query message after receiving one query message sent from the querier, and if the timer expires, it means that one query message has been lost, and when the number of conditions like overtime is up to a certain threshold value (called robustness variable, usually take a value of 2), the non-querier thinks the querier is faulted and sets the state of itself immediately to be the querier and sends out the query message. There are two functions for the message, and one is judging which multicast group there is a member joining according to a message replied by each host after receiving the query message, and the other is choosing one querier again via the query message if there is still at least one non-querier for this time.
The above method has three defects: firstly, the period of switching the non-querier to be the querier is too long, because the switching of querier depends on the frequency of the querier sending the query message, and since the query message is mainly used for the interaction between the querier and a large number of hosts to maintain the relationship between multicast group members, the querying period of the querier is usually configured to be relatively longer (the default period is 125 seconds), namely, the non-querier generally needs more than 250 seconds (multiply the querying period by the robustness variable) to judge that itself has been switched to be the querier; secondly, the non-querier still needs to send the query message and receive the reply message sent from each host to determine which multicast group user demands are included in after switched to be the querier, and the time depends on the time required by receiving the reply message after sending the query message, which is usually a default value of 10 seconds; thirdly, if a dynamic multicast protocol is performed between the non-querier and an upper network (such as IGMP, PIM and so on), the non-querier initiates a request to the upper network and brings in the multicast flow from the upper network after determining which multicast group the user demands are included in, and the period depends on architecture of the upper network and speed of the upper equipment receiving and processing the request, and the time required by sending a data flow to the querier after processing. The above three defects result in that after the original querier or the downlink of the querier is faulted, the non-querier is switched to be the querier and finally sends the multicast flow to each host according to the member relationship of each multicast group, which requires a very long period.